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Язык описания политик подписания. 
Схема и возможности 


Описано предназначение и функциональное наполнение политик подписания. Представлена ОМТ- 
схема ее представления и показано использование политик подписания на примере государственных 
тендерных закупок. 


Введение 


Внедрение в Украине общественной структуры для поддержки электронной 
цифровой подписи (ЭЦП) требуют строгого описания и поддержания политик безоп- 
асности. Это связано с необходимостью повышения конкурентоспособности при 
использовании в еСоттегсе, еТгапзрой и еСоуегитепь внутри страны и за ее 
пределами, что невозможно без гарантированного обеспечения уровня доверия и 
надежности таких систем. К тому же, вступление Украины в ВТО требует создания 
интеллектуальных систем, способных анализировать, сравнивать и выполнять 
разновидности политик безопасности согласно требованиям обеспечения транзакций 
в разных странах и бизнес-алгоритмах. 

Один из недостатков текущих спецификаций и соответственно реализаций 
ЭЦП - отсутствие прямой связи семантики бизнес-алгоритмов с ЭЦП, поскольку 
семантика распознается косвенно, через контекст транзакции. Такой механизм 
недопустим в системах с повышенными требованиями к надежности и безопасности 
транзакций, например, государственных закупок, банковских транзакций и т.п. 

Для привязки семантики к дополнительным правилам верификации и валидации 
ЭЦП разработана концепция политики подписания, предполагающая ее разновидности. 
Политики подписания — пока слаборазвитое поле, в первую очередь ввиду нечеткости 
границ их использования и недостатка опыта стандартизации. А механизм описания 
политик подписания — критически важный инструмент для поддержки валидации ЭЦИ 
на этапе подписания и привязки четкой семантической нагрузки ЭЦП. 

В этой статье рассмотрены требования к политике подписания, в частности ее 
функционального наполнения. Предложен расширяемый механизм описания поли- 
тик подписания, который в частности допускает организацию автоматического срав- 
нения политик подписания. 


1. Определение поля использования политик 
подписания 


Для определения контекста и функционального наполнения политик подписания 
рассмотрим определение политики безопасности для общественной структуры 
поддержания ЭЦП. Политика безопасности — документ, декларирующий, как компания 
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планирует защитить свои физические и информационно-технологические активы. 
Как «живой документ», политика безопасности означает, что формирование 
документа перманентно не завершается, он непрерывно обновляется по требованиям 
технологий и обслуживающего персонала. 

Согласно Директиве [1], общественную структуру в поддержку ЭЦП 
составляют множества субъектов и объектов, каждый из которых имеет свои 
политики безопасности, которые включают, например, требования к политикам 
сертификации для провайдеров, выдающих усиленные сертификаты [2], требования 
к политикам органов штемпелевания времени [3] и т.п. Одна из составляющих 
политики безопасности — политика подписания, которая согласно «Отчету о поли- 
тиках подписания» [4] есть набор правил для создания и валидации ЭЦП, используя 
который ЭЦП можно определить как валидную. Поскольку политика — общий способ 
выразить функциональные условия электронного бизнеса, политику подписания 
нужно отличать от другой составляющей политики безопасности — политики 
сертификации, содержащей правила, которые среди прочего определяют, какая 
политика сертификации приемлема под конкретной политикой подписания. Это 
ограничивает сертификаты открытых ключей, используемые под политикой под- 
писания, поскольку эти сертификаты должны содержать информацию (например, 
ОГО), указывающую, что они выполняют «такую» политику сертификации. 

Далее определим, (1) контекст использования политики подписания, (2) ее 
контент или функциональное наполнение, (3) поле использования. 


1.1. Контекст использования 


1.1.1. Контекст транзакции. Поскольку политика подписания может задавать 
требования, ассоциированные с транзакциями, необходимо связать ее со специфическими 
базовыми элементами политики подписания, предназначенными для такой форма- 
лизации. Контекст транзакции может включать коммерческий, административный, част- 
ные аспекты или их комбинацию. Контекст транзакции определяет общие приемлемые 
правила, ассоциированные с процедурами подписания. Такие правила могут произойти 
из состояний, например, действие должно быть предпринято при заполнении опреде- 
ленной формы согласно корпоративным условиям. 

Например, центры сертификации ключей в Украине продают клиентам ЭЦП, 
ассоциированные с разным уровнем криптозащиты и, разумеется, с разной стоимостью: 
электронная печать компании, ЭЦП главного менеджера компании, бухгалтера и других 
служащих. Разумеется, виды электронных документов, исходящих из компании, 
следует подписывать разными ЭЦП согласно строгим процедурам организации 
электронного документооборота как основы политик подписания. 

1.1.2. Политика подписания в пределах РКТ. В среде РКТ, когда подписант в 
цифровой форме подписывает данные, необходимо указать, что ЭЦП имеет определенное 
значение. ЭЦИ может подтолкнуть подписанта к действию, связанному с выраженной 
фиксацией транзакции, или просто использовать как вызов, когда необходима аутенти- 
фикация. Когда у ЭЦП есть определенное значение, подписант обязан включить инди- 
кацию этого в подписанную структуру о том, что ЭЦП -— фиксация транзакции. 

Как индикация политика подписания обеспечивает нотацию относительно 
преобладающих правил и условий, которые подписант формулирует для третьих 
лиц, включая зависимые стороны, которые полагаются на его ЭЦП. 
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1.2. Контент политики подписания 


Политика подписания определяет технические и процедурные требования 
относительно создания подписи и ее валидации для соответствия определенным бизнес- 
потребностям. Политика подписания должна существовать в двух формах: 

— понятных всем пользователям; 
— обрабатываемых компьютером, возможно, внутренних встроенных кодах или 
внешних кодах, интерпретируемых компьютером. 

Автоматизированную валидацию ЭЦП можно использовать в транзакциях, 
основанных на ЕПМ-форматах электронного обмена данными (Нестомс ПОаа 
ПиегсВапое). ЕБ]-транзакции включают транзакции таких финансовых услуг, как 
передача электронных фондов (ЕЕТ — Несвотшс Рипа Тгап$Ёег), обычно основанных 
на стандартах ОМ/ЕОТЕАСТ [5]. Более новый формат для обмена структурированными 
данными основан на ХМГ, в частности е ХМГ [6] как формат данных для обмена 
документа во всемирной паутине (\У\ У). 

Согласно [4] общая информация о политике подписания включает: 

1. Имя издателя политики подписания (А 51епафге РоПсу 155иег пате). 

2. Идентификатор политики подписания (А З1епахе Ро|су 1Ч4епийег). 

3. Период подписания (А $1е пс репо9). 

4. Дата издания (А Рае оЁ1551е). 

5. Поле применения (А Ре оЁ АррПсаНоп). 

Определенные фиксации (сот!) транзакции, которые могут предпринимать 
участники транзакции, могут также составлять часть политики подписания. Такие 
фиксации транзакции устанавливают транзакционную структуру для использования 
цифровых подписей, подписывая документ. Тип фиксации транзакции может быть 
объектным идентификатором с квалификатором, обеспечивающим подробную инфор- 
мацию о фиксации транзакции, например, информацию о договорном/юридическом/ 
прикладном контексте. 

1.2.1. Информация о валидации ЭЦП. Информацию о валидации ЭЦП можно 
включать в общие правила или в правила фиксации транзакции, но в любом случае 
они не должны вступать в противоречие. Издатель политики подписания должен 
будет выбрать информационные элементы валидации ЭЦП, приемлемые для данной 
политики валидации ЭЦП. Информационные элементы валидации ЭЦП включают: 

1) правила для использования органами сертификации (то есть требования 
построения пути сертификатов); 

2) правила, относящиеся к пользовательскому сертификату; 

3) правила удостоверения, что ЭЦП создана в то время, когда сертификат был 
валиден (то есть верхний предел времени валидности ЭЦП либо наличие временного 
штемпеля или метки времени); 

4) правила для предостерегающего периода; 

5) правила для использования информации о состоянии аннулирования (то 
есть требования аннулирования); 

6) правила для защиты от компрометации ключа органа сертификации и 
слабой криптографии; 

7) правила, касающиеся среды, которую будет использовать подписант; 

8) данные верификации подписи, которые будут предоставлены подписанту 
или собраны верификатором; 

9) любые ограничения на алгоритмы подписания и длину ключа; 
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10) правила для использования ролей субъектов политики безопасности; 

11) требования построения пути сертификатов. 

Требования сертификации идентифицируют последовательность надежных при- 
вязок, используемых для запуска (окончания) обработки пути сертификатов и началь- 
ные условия для его валидации, как определено в ТЕТЕ ВЕС 2459 [7]. Детальная 
информация в «Отчете о политиках подписания» [4]. 


2. Язык описания политики подписания 


В [8] представлена общая ХМГ-разметка для ссылки на политики подписания в 
рамках стандарта ХМГ-формата ЭЦП [9], но непосредственно отсутствует разметка для 
описания политик подписания. Для создания языка описания политик подписания реко- 
мендуется глубоко исследовать и при необходимости разработать стандарты [10], [11]. 
В этой статье изучены новые версии этих стандартов [12], [13]. 


2. РЭВ 


Платформа для проекта приватных предпочтений (РЗР) позволяет веб-сайтам 
выразить свои приватные предпочтения в стандартном формате, может быть извле- 
чена автоматически и легко интерпретироваться пользовательскими агентами. Именно 
они информируют пользователей о методах сайта (в машино- и человеко-читаемых 
формах) и автоматизируют принятие решений, основанное на этих методах. Таким 
образом, пользователи не должны учитывать политику конфиденциальности на каж- 
дом сайте, который они посещают. 

Хотя Р3ЗР гарантирует, что пользователям будет сообщено о политике конфиден- 
циальности прежде, чем они передадут личную информацию, РЗР не обеспечивает 
механизм для удостоверения, что сайт функционирует согласно своей политике. РЗР- 
продукты могут способствовать этому, но это — специфика реализации. Однако РЗР 
является дополнением к законам и саморегулируемым программам, способным 
обеспечить механизмы, которые выполнят это требование. Кроме того, РЗР не имеет 
механизмов передачи данных или поддержки безопасности при передаче или хранении 
персональных данных. РЗР можно встроить в инструменты, облегчающие передачу 
данных и обеспечивающие соответствующие гарантии защиты информации. 

Реализуя специфические требования для выражения политик конфиденциальности, 
РЗР имеет более слабый механизм расширения и уступает КПЕ, что явно демонстрирует 
наличие КОЕ-разметки для Р3ЗР-политик конфиденциальности [15]. Механизм расши- 
рения критичен для политик безопасности, поскольку они являются «живыми докумен- 
тами», постоянно изменяемыми и расширяемыми. 


2.2. КОЕ 


Разработка «КОЕ/ХМГ, Зущах Зрес!сайоп (Кеу1зе4)» наиболее перспективна с 
позиций гибкости механизмов. Согласно [14] структура для описания ресурсов 
(КРЕ- Везоигсе Оезсирйоп Егатехмог®) является языком представления информации 
о ресурсах в \/\М/ У. Он предназначен для представления метаданных о таких ре- 
сурсах сети, как имя, автор и дата модификации веб-сайта, авторского права и лицен- 
зионную информацию о документе сети или списке доступности для некоторого общего 
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ресурса. Обобщив понятие ресурса сети, КОРЕ можно использовать для представления 
данных о сущностях, идентифицируемых в сети, даже когда их невозможно непо- 
средственно восстановить из сети. 


Бер://ууу\и №3 .0т5/2000/10 
/5\мар/рит/сошас Регзоп 


Бер://\му\иу м3 .ого/Реор[е 
/ЕМ/сощас те 


Еис МШег 


таю:ет@\3.оте 


Рисунок 1 — Пример схемы описания контакта с человеком 


ВПЕ предназначен для ситуаций, в которых эту информацию обрабатывает 
приложение. ВПЕ служит общей основой для выражения этих данных, поэтому ими 
могут обменяться приложения без потери значений. Поскольку это — общая струк- 
тура, разработчики могут усилить пригодность общих анализаторов ВПЕ и инстру- 
ментов обработки. 

ВПР основан на идее идентификации сущности с использованием идентификаторов 
сети ЧВ5 (унифицированных идентификаторов ресурса) и описанием ресурса в терминах 
простых свойств и значений свойств. Это позволяет КПЕ представить простые утверж- 
дения о ресурсах как граф узлов и дуг, представляющих ресурсы, их свойства и значения. 
Для примера на рис. 1 приведен КОЕ-граф для утверждения «есть человек, идентифи- 
цированный Бр://\у\лу м3З.ого/Реоре/ЕМ/сотасё те, чье имя — Эрик МШег, чей адрес 
электронной почты — ет(@5\3.отге, и чья приставка — д-р». 

Гибкость и простота механизмов ВОЕ способствуют спецификации политик 
подписания. Это обусловлено механизмом свойств, типизацией и использованием 
О ВТ. Далее детально о каждом свойстве. 

1. ВБЕ описывает ресурс в понятиях свойств. 

2. ВБЕ не имеет своих внутренних типов, а использует внешние определения, 
как правило, стандартные для ХМГ [16]. Пример типизированного свойства «1999- 
08-16»^^х54:аже, где хз — схема ВИр://\у\и. МЗ .ого/ТВ/хиазсВета-2/. 

3. Как НТМЕ, КОЕ/ХМЕ -— машино-обрабатываемый и, используя ОВТ, может 
связать информацию через сеть. Однако в отличие от обычного гипертекста ВОЕ 
ОВТ может обратиться к любой опознаваемой сущности, включая сущности, 
непосредственно не извлекаемые из сети (скажем, человек Эрик МШег). 

Привлекательное свойство модели КОРЕ — организация привязки свойств к 
объектам. В отличие от традиционной для программирования объектной модели, 
когда класс содержит свойства, свойства существуют в рамках класса, а заполнение 
свойств обязательно, в модели КПЕ классы привязывают к свойствам, то есть одно 
свойство может быть элементом множества или несвязанных между собой классов, а 
заполнять свойства необязательно. 
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Модели КПЕ имеют существенные недостатки, препятствующие ее использованию 
для описания политик подписания: 

[) ограничения мощности на свойства, например, у человека есть точно один 
биологический отец; 

2) определение, что данное свойство (скажем, ех:ВазАпсезюг) является транзитив- 
ным, например если А ех:ВазАпсезюг В и В ех:ВазАпсез{г С, то А ех:;ВазАпсезюг С; 

3) определение, что данное свойство — уникальный идентификатор (или ключ) 
для случаев специфического класса; 

4) определение, что два разных класса (имеющих разные ОКПеё) фактически 
представляют один класс; 

5) определение, что два различных экземпляра класса (имеющих разные ОВПев) 
фактически представляют одни экземпляр класса; 

6) определения ограничений на диапазон или мощность свойств, зависящих от 
класса ресурса, к которому применено свойство, например, для футбольной команды 
свойство ех:НазР1ауегз имеет 11 значений, а для баскетбольной — только 5 значений; 

7) способность описать новые классы в терминах комбинаций (например, 
объединения и пересечения) других классов или сказать, что два класса являются 
разбиением (то есть не существует экземпляра, который одновременно является 
экземпляром обоих классов). 

Развитие разметки ВПЕ, именуемой О\МТ, [17], снимает эти ограничения. 


2.3. О\УЕ 


Язык ОУ\Т, обеспечивает три выразительных диалекта, разработанных для исполь- 
зования определенными сообществами архитекторов и пользователей. 

О\МТ, Гще поддерживает пользователей, прежде всего нуждающихся в иерар- 
хической классификации и простом ограничении свойств. Например, хотя О\МГ, Гще 
ограничивает мощность, он допускает только значения мощности 0 или 1. Более 
простым должен быть инструмент поддерживающего О\Т, Гие, чем его более 
выразительных родственников, чтобы обеспечить быстрый переход для тезаурусов и 
других таксономий [17]. 

ОУТ, — модель и схема, в которой спецификация политик подписания будет 
наиболее полной и строгой, что критически важно для бизнес-транзакций. 

Одновременно модель ОУ!Т, дает возможность ужесточить требования и пере- 
вести язык описания в область экспертных систем, то есть в О\ЗМГ. ОГ. Даже без 
перехода в О\МТ, ОГ можно сравнить политики подписания, используя конструкты 
группы ()ЕдиаП у, которые обеспечивают сравнение классов и свойств, реализа- 
цию инверсии и транзитивности. 

Используя синтаксис О\УГ, определим схему для описания политик подписа- 
ния, в которой реализованные атрибуты, идентифицированные в 1.2. Сама схема 
приведена в разделе 3, а пример применения - в разделе 4. 


3. О\М!Т-схема описания политик подписания 


Исходя из определения политики подписания, ее составляющие представлены 
на рис. 2. Здесь З1епайитеРоЙсу как политика подписания состоит из: 
— Базовых свойств (Соге РгорегЧез) — специфицирует базовые свойства, без которых 
невозможна публикация политики подписания. Более детальное описание свойств 1.2. 
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— Базовых правил (Соге Вче;) — специфицирует базовые критерии, выполнение 
которых гарантирует валидность подписи. 

— Правил уровня транзакции (Тгапзасйоп Сомех{ Вшез) — специфицирует базовые 
критерии, выполнение которых идентифицирует фиксацию транзакции. 


З1опавиеРойсу 


оп (ОЕ 
с018150 с018150 
Тгапзасной 
- | Сощех( Кез 
Вауе ауе 


З1опавите 
: Ронсу [5иег РаеОЕ 
Реной ИК им. В.М. еще. | 0112.07 
Мате 
Глушкова 


ОШМаог Мегоп ОВемюл питбег 


Заае `ЖааБае 


ОШМшог\уег1оп Э1епайге 
] РоЙсу 
2 3 01.01.08 01.01.11 [депёйег 77.71.45 


Рисунок 2 — Базовые элементы политик подписания 


Конкретная спецификация базовых правил и правил уровня транзакции зависит 
от контекста использования политики подписания. Полноценное использование поли- 
тики подписания, с полной спецификацией всех основных составляющих, продемон- 
стрировано далее на конкретном примере. 


4. Пример использования политики подписания 


Рассмотрим процедуру приглашения для участия в государственных тендерных 
закупках. Отметим, что это одно из множества применений политики подписания. 

Этот сценарий актуален сегодня в Украине, вступившей в ВТО, а предло- 
женное применение можно распространить на предприятия любого размера, причем 
унификация процесса тендерных закупок снизит стоимость программного обеспе- 
чения и оптимизирует затраты предприятий и государства в целом. 

Рассматривая государственные закупки, задействуем законопроект «Про закупку 
товаров, работ и услуг за государственные средства» [19]. В частности в параграфе 2 
статьи 13 указано: «Замовник мае право зийснити закушвлю за одн!ею з процедур, 
зазначених у частин! перпий це! статт! (кр1м процедур торгв з обмеженою участю 
та закушвл!1 у одного учасника), шляхом здИснення електронних закушвель з 
використанням 1нформащйно! системи в 1нтернет з дотриманням вимог, установ- 
лених цим Законом та 1ншими актами законодавства Украни». 

В рамках концепции базовых компонентов [20] ОМ/СЕРАСТ разработал бизнес- 
модель и ХМГ-форматы обменных документов для организации тендерных закупок, 
соответствующие требованиям ВТО. Этот проект еТеп4ени» разрабатывает комитет 
ТВО6 ОМ/СЕРКАСТ [21]. 
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Стандартизированные бизнес-процессы и документы обеспечат максимальную 
интероперабельность систем и прозрачность процессов. Использование наработок 
ОМ/СЕЕАСТ целесообразно и желательно в связи с положениями законопроекта, в 
частности с предназначением, указанным в пояснительной записке [22]: «Метою 
прийняття законопроекту е встановлення правових та економ1чних засад здйснення 
процедур державних закушвель для забезпечення реального дотримання сучасних 
принцишв державних закущвель та подалыьшо! гармонзаий нашонального законодавства 
щодо державних закушвель з нормами аналоёчного мёжнародного законодавства, 
зокрема Евросоюзу та у межах вступу Украни до СОТ». 

Участвующие в приглашении стороны -— это организатор, участник и гарант. 
Валидными являются ЭЦП, когда каждый участник выполнил требования: 

1. Организатор своей ЭЦП гарантирует корректность своих реквизитов, 
подтверждая номер тендера и связанную с ним информацию. 

2. Включенные в приглашения реквизиты и параметры участника также под- 
писаны предварительно зарегистрированным участником, при этом в характеристике 
предприятия указаны сертификаты необходимой квалификации персонала и серти- 
фикаты предприятия (скажем, о качестве выпускаемой продукции), подписанные 
соответствующими органами. 

3. Гарант указывает свои реквизиты и дополнительные данные, подтверждаю- 
щие корректность реквизитов и достаточность финансовых средств, оцененных и 
подписанных независимым оценщиком, для обеспечения гарантий между участни- 
ком и организатором тендера, если его выиграет участник. 

Только при условии выполнения указанных требований валидна ЭЦП на 
приглашении. Для выполнения поставленной задачи необходимо: 

1. Описать бизнес-процесс. 

2. Описать политику подписания, согласно требованиям тендера. 

3. Указать методы валидации подписи на основе политики подписания. 


Верифицирует 
риглашение 


Передает 
приглашение 


Организатор 


Рисунок 3 — Передача приглашения участнику организатором 


Конкретная спецификация базовых правил и правил уровня транзакции зависит 
от контекста использования политики подписания и может выглядеть негативно для 
определения политики подписания. На самом деле это не так, в идеологии инфра- 
структуры еб ХМГ, УМ/СЕЕАСТ разрабатывает библиотеки стандартных, базовых 
атрибутов любого документа еСоттегсе, еСоуеглтепе и еТгапзрог. А еТепдепие® пол- 
ностью базируется на идеологии базовых библиотек, поэтому можно выработать общий 
механизм спецификации политик подписания. 

Бизнес-процесс показан на рис. 2. Политики подписания согласно вышеуказанным 
требованиям выглядят как на рис. 4. 

Построение такой иерархии основано на источниках информации, указанных в 
политике подписания и ВОМ-модели ХМГ-документа приглашения (рис. 5 и рис. 6). 


«Штучний 1нтелект» 32008 101 


Мелащенко А.О. 


с01815ЮЁ с01$15 ОТ 


с01$15ЮЕ 


Ведитетет$ Рог Ведитетеп$ Юг 


РгосигетепВ едит СагапОгеашганоп 
о РгосиниеРгоес+ 
эОтоашханоп 
14 оа1Видэе 
Атб 
Мате 
12457 1100000 о р 
соп$15 ОР 
Кабинет министров 
Украины Ведипетет Юг 
РгосиаеОгваштаноп 
Мате 
Интерпайп Вауе 
с0115ОЁ — 
с01315ОЁ 
Туре 
ы Оуупег 
150 9001 ООО «Интерпайп Украина» 


Рисунок 4 — Дополнительные правила валидации подписи 
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Рисунок 5 — Общая ВОМ-модель ХМГ-документа, описывающая приглашение 
на тендер, и РОМ-модель части ХМГ-документа с атрибутами организатора 


Источники данных, на основе которых заполняются множества допустимых 
значений политики подписания, таковы: 

1. Реквизиты организатора — путь сертификации. 

2. Номер и данные о тендере — сайт организатора тендера. 

3. Реквизиты участника, к которым имеет прямой или косвенный доступ прог- 
рамма верификации данных. 
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4. Сертификаты о квалификации персонала для участника и наличие средств 
для гаранта — сайты соответствующих органов сертификации. 


В 
Маше 4 
Пуегпабопа Мате ДезсирНоп 
14 Мате 
Вигеа!а ТуреСоде 


Рисунок 6 —- РОМ-модель части ХМГ-документа, описывающая атрибуты участника, 
и РОМ-модель части ХМГ-документа, описывающая атрибуты тендера 


Язык ОУТ, позволяет задать ООМ-модель политики подписания и определить 
пространство значений конкретных экземпляров документов и их полей. Используя 
политику подписания, для валидации документа необходимо сравнить конкретные 
элементы (поля) в РОМ-модели документа, согласно которой политика подписания 
характеризуется множеством возможных значений любого экземпляра документа. 
Наращивание функционала происходит добавлением вершин в графовую РОМ-модель, 
согласно политике подписания и документу соответственно. Определения уникальных 
идентификаторов, функциональных зависимостей и транзитивности языка ОУМТ, позво- 
ляют модифицировать ООМ-модель политики подписания для более глубоких сравнений 
и спецификаций. Ввиду использования языка О\УМТ,, спецификация политики подписания 
гарантирует вычислимость выражений О\\Т, и обработки их интеллектуальными аген- 
тами, преследующими цели, поставленные пользователем. 

Таким образом, проанализировав содержание ООМ-модели ХМГ-документа 
приглашения на наличие допустимых значений всех атрибутов, можно установить 
валидность подписи на приглашении. 


Выводы 


Политики подписания — это составляющие политик безопасности в обществен- 
ной структуре для поддержки электронных подписей. Политика подписания как 
механизм позволяет связать семантику с ЭЦП, таким образом, повышая доверие и 
надежность для еСотитегсе. 

Нынче отсутствуют стандарты и даже специализированные разработки для пре- 
доставления политики подписания, ввиду сложности данных, непосредственно вклю- 
ченных в политику подписания, а также самой «живой» природы политики, то есть 
постоянно изменяющейся под потребности технологий и обслуживающего персонала. 

В статье идентифицирован основной контент политики подписания и исследо- 
ваны языки разметки для представления разнообразных данных в целях политики 
подписания. На примере организации тендерных закупок по правилам ВТО показана 
адаптация языка разметки О\!Г,, идеально подходящего для предоставления «живой 
информации» и имеющего встроенные средства наращивания семантического богат- 
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ства и механизмов политик подписания. Использование человеко- и машино-читае- 
мых политик подписания позволяет увеличить доверие и надежность еСоттегсе и 
достичь автоматического выполнения юридических и технических требований В 
разных странах и бизнесах. 
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Мова опису полтик шдписання. Схема й можливост! 

Описано призначення й функцюнальне наповнення политики шдписання. Наведено О\Т-схему Й подання 
й показано застосування полтики шдписання на приклад! державних тендерних закушвель. 
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